Snowflake Trust Center を試してみた #SnowflakeDB

モダンデータスタック(MDS)

#Snowflake

安原朋紀

2024.06.03

2024年5月のリリースで Snowsight 上で Snowflake アカウントのセキュリティリスクを評価、監視できる機能である Trust Center がパブリックプレビューとなりました。
こちらの機能を試してみたので記事としました。

Trust Center の概要

Trust Center は Scanner Package として提供される各スキャナーで指定されたセキュリティ上の推奨事項を定期的に評価・モニタリングできる機能です。
評価された結果は Snowsight 上で確認することが可能で、各項目について必要に応じて対応を行えます。

CIS ベンチマークスキャナーパッケージ

執筆時点ではスキャナーとして「CIS ベンチマークスキャナーパッケージ」が提供されており、こちらに基づく評価指標をチェックすることができます。
Snowflake に関するこのベンチマークの詳細は以下よりダウンロード可能です。

このベンチマークでは、大きくわけて以下の４つの観点からならる全39の推奨項目が提供されています。

Identity and Access Management
Monitoring and Alerting
Networking
Data Protection

以下の記事では各項目について日本語で概要を解説してくださっていますので、あわせてご覧ください。

以下は公式ドキュメントを日本語訳した内容の引用ですが、このベンチマーク適用時の注意点として以下があります。

一部のベンチマークでは、Snowflake は特定のセキュリティ対策が実装されているかどうかのみを判定しますが、セキュリティ対策が目的を達成する方法で実装されているかどうかは評価しません。これらのベンチマークでは、違反がなくてもセキュリティ対策が効果的に実装されていることが保証されるわけではありません。次のベンチマークでは、セキュリティ実装が目的を達成する方法で実装されているかどうかは評価されず、Trust Center ではそれらのチェックは実行されません。

2 : 監視と警告

3.1 : アカウントレベルのネットワークポリシーが、信頼できる IP アドレスからのアクセスのみを許可するように構成されていることを確認します。アカウントレベルのネットワークポリシーがない場合、セキュリティセンターは違反を表示しますが、適切な IP アドレスが許可されているかブロックされているかは評価しません。

4.3 : 重要なデータに対して DATA_RETENTION_TIME_IN_DAYS パラメータが 90 に設定されていることを確認します。Trust Center では、 Time Travelに関連付けられたDATA_RETENTION_TIME_IN_DAYSパラメータがアカウントまたは少なくとも 1 つのオブジェクトに対して 90 日に設定されていない場合に違反が表示されますが、どのデータが重要と見なされるかは評価されません。

4.10 : 機密データに対してデータマスキングが有効になっていることを確認します。アカウントに少なくとも 1 つのマスキングポリシーがない場合、セキュリティセンターは違反を表示しますが、機密データが適切に保護されているかどうかは評価しません。セキュリティセンターは、少なくとも 1 つのテーブルまたはビューにマスキングポリシーが割り当てられているかどうかを評価しません。

4.11 : 機密データに対して行アクセスポリシーが構成されていることを確認します。アカウントに少なくとも 1 つの行アクセスポリシーがない場合、セキュリティセンターは違反を表示しますが、機密データが保護されているかどうかは評価しません。セキュリティセンターは、行アクセスポリシーが少なくとも 1 つのテーブルまたはビューに割り当てられているかどうかを評価しません。

つまり、ベンチマークの観点の一つである「Monitoring and Alerting」についてはチェックが行われず、また上記の項目 3.1、4.3、4.10、4.11 については各項目がアカウントで少なくとも設定されているか、またはポリシーが存在するかどうかのみ評価を行います。なので、例えばマスキングポリシーであれば、アカウント内でこのポリシーを設定すべきテーブルカラム全てに網羅されているかどうかの判定まではできないので、ユーザー側で確認しておく必要がある点はご注意ください。

制約

現時点の主な制約は以下です。

スキャナーパッケージとして CIS ベンチマークスキャナーパッケージのみ提供
トライアルアカウントでは利用不可

事前準備

機能の検証用に、ここでは事前に以下の作業を行いました。

検証用のアカウントを作成
アカウントを作成時に指定したユーザーに対する MFA 設定

アクセス制御

Trust Center の使用に関して以下のアプリケーションロールが提供されています。

SNOWFLAKE.TRUST_CENTER_ADMIN
- Trust Center の管理者用ロール
- スキャナーパッケージの実行にはこのロールに紐づく権限が必要
SNOWFLAKE.TRUST_CENTER_VIEWER
- Trust Center による評価結果の閲覧用ロール

デフォルトでは ACCOUNTADMIN が使用できるので、必要に応じてそれぞれ以下のコマンドで権限を付与します。

USE ROLE ACCOUNTADMIN;
--Trust Center の管理者用ロールの作成
CREATE ROLE trust_center_admin_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN TO ROLE trust_center_admin_role;
--Trust Center による評価結果の閲覧用ロールの作成
CREATE ROLE trust_center_viewer_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER TO ROLE trust_center_viewer_role;
--各ロールをユーザーに割り当て
GRANT ROLE trust_center_admin_role TO USER example_admin_user;
GRANT ROLE trust_center_viewer_role TO USER example_nonadmin_user;

試してみる

上記のコマンドで管理者用ロールを作成し、使用可能なユーザーで Snowsight にログインし「Monitoring > Trust Center」をクリックします。

メニューは「Findings」と「Scanner Packages」のタブに分かれており、「Findings」には TRUST_CENTER_VIEWER または TRUST_CENTER_ADMIN、「Scanner Packages」タブを表示するには TRUST_CENTER_ADMIN ロールが必要です。
また、この画面を表示するためにも別途何らかのウェアハウスに対する使用権限が必要です。

スキャナーパッケージの表示

ここでは TRUST_CENTER_ADMIN ロールの権限を持つユーザーで操作しているので Scanner Packages タブを開きます。すると下図のようにデフォルトのパッケージとして「CIS Benchmarks」が表示されます。

パッケージを選択すると具体的な項目が表示されます。

スキャナーパッケージの有効化

パッケージを選択した画面から「Enable」を選択すると毎時～月次、カスタムであれば CRON を使用するなどスキャナーパッケージを実行する任意のスケジュールを指定できます。

任意のスケジュールを指定し [Continue] をクリックするとパッケージが有効化され同時にはじめの実行が行われます。

評価結果の表示

パッケージの有効化後、しばらくすると「Findings」タブに評価結果の変遷を時系列で確認できるグラフとパッケージの各項目の内、リスクとして検出された項目が一覧で表示されます。各項目は事前に Low, Medium, High, Critical の４段階からなる SEVERITY に分類されているようで、グラフでもこのレベルごとに表示されます。

評価結果のグラフ

リスクとして検出された項目
- ここで表示されるのは最後のスキャナーの最新実行時にリスクとして検出された項目です。前日など複数回実行した場合であっても、前回実行時の検出項目の表示は現時点ではできませんでした。

各評価項目をクリックすると「Remediation」と「Summary」タブでさらに詳細を確認できるようになっています。

Remediation
- ここでは項目によっては具体的な SQL コマンドもあわせて修復手順を確認できます

Summary
- 評価項目の詳細や違反するオブジェクトが表示されます

スキャナーパッケージの無効化

有効化したパッケージは指定の頻度で実行されるため、停止したい場合は [Scanner Packages] タブから停止したいパッケージを選択し [Settings] タブ内の「Disable Scanner Package」を選択することで停止できます。

注意点として、パッケージを停止すると過去の結果も表示されなくなります。

セキュリティリスクの修復

ここでは事前準備にあるように、アカウントの作成段階で ACCOUNTADMIN ユーザーの MFA を実施したのみでしたが、上記の 16 項目がリスクとして検出されました。
一部リスクを修復後、再度スキャナーが実行されるとどのような表示になるのかを確認するために、ここでは以下の項目について修正を行ってみました。

1.5 Ensure minimum password length is set to 14 characters or more

ユーザーのパスワードが少なくとも14文字以上として設定されているか、という項目です。Snowflake のアカウント作成段階では「abc123」などのパスワードを設定できてしまうので、Password Policy により最小文字数やパスワードに数字や特殊文字を含むかなど任意の要件を設定できます。

この項目をクリックすると下図のようにパスワードポリシーの修復コマンドの例が表示されます。

パスワードポリシーはスキーマレベルのオブジェクトなので、ポリシーを作成後、アカウントレベルで設定を行いました。

ALTER ACCOUNT
SET PASSWORD POLICY my_password_policy;

詳細な手順は以下の記事をご参照ください。

4.10 Ensure that data masking is enabled for sensitive data

こちらは機密データがマスキングされているかどうかの検証項目で、上述の通りここではアカウント内にマスキングポリシー無い場合、リスクとして検出されます。そのため、ポリシーを作成するのみで検出されなくなるためご注意ください。つまり、テーブルカラムに適用されていなくても検出されなくなり、また適切なカラムに適用されているかどうかまでの判断はできません。

修復手順としては、タグベースのマスキングポリシーやこのために分類機能が使用できる点が言及されていました。Snowflake における機密データの分類機能については以下をご参照ください。

ここでは以下のコマンドで適当なデータに対してマスキングポリシーを適用してみました。

マスキングポリシーの設定

--ロールの作成
USE ROLE securityadmin;
CREATE OR REPLACE ROLE test_admin;
CREATE OR REPLACE ROLE analyst;

GRANT ROLE analyst TO ROLE test_admin;
GRANT ROLE test_admin TO ROLE SYSADMIN;

--データベースを作成
USE ROLE sysadmin;
USE WAREHOUSE compute_wh;

CREATE OR REPLACE DATABASE test_db;

GRANT OWNERSHIP ON DATABASE test_db TO ROLE test_admin;
GRANT OWNERSHIP ON SCHEMA test_db.public TO ROLE test_admin;

GRANT USAGE ON WAREHOUSE compute_wh TO ROLE analyst;

--PJ管理者にスイッチ
USE ROLE test_admin;
USE SCHEMA test_db.public;
USE WAREHOUSE compute_wh;

--テーブル作成
CREATE OR REPLACE TABLE employee_data (
    id INTEGER PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(100),
    phone_number VARCHAR(15),
    department VARCHAR(50)
);

INSERT INTO employee_data (id, name, email, phone_number, department) VALUES
(1, '田中太郎', 'tanaka.taro@example.com', '012-3456-7890', '営業部'),
(2, '佐藤花子', 'sato.hanako@example.com', '012-3456-7891', '人事部'),
(3, '鈴木一郎', 'suzuki.ichiro@example.com', '012-3456-7892', 'IT部'),
(4, '高橋真子', 'takahashi.mako@example.com', '012-3456-7893', '営業部'),
(5, '中村悟', 'nakamura.satoru@example.com', '012-3456-7894', '総務部');

--権限付与
GRANT USAGE ON DATABASE test_db TO ROLE analyst;
GRANT USAGE ON ALL SCHEMAS IN DATABASE test_db TO ROLE analyst;
GRANT SELECT ON ALL TABLES IN DATABASE test_db TO ROLE analyst;

--マスキングポリシー
USE ROLE test_admin;
CREATE OR REPLACE MASKING POLICY email_mask AS (val string) returns string ->
  CASE
    WHEN current_role() IN ('TEST_ADMIN') THEN VAL
    ELSE '*********'
  END;

--masking policyを適用
ALTER TABLE IF EXISTS employee_data MODIFY COLUMN email SET MASKING POLICY email_mask;

--確認
USE ROLE analyst;
USE WAREHOUSE COMPUTE_WH;
SELECT * FROM employee_data;

再度スキャナーパッケージを実行

上記の手順を実行後、再度スキャナーパッケージを実行しました。
パッケージを手動実行する際は、パッケージの「Scanners」タブ内の更新マークをクリックします。

実行後、ここでは下図の表示となりました。「2項目リスクが減少した」という結果でした。
※わかりづらくて恐縮ですが、一度スキャナーパッケージを無効化して一日経った後に再度有効化したので、6/1 が何もない表示となってしまっています。

ここでは初回実行時はリスクとして検出されていた内の、以下の項目が検出されなくなっていました。

1.16 Ensure that Snowflake stored procedures are not owned by the ACCOUNTADMIN or SECURITYADMIN roles
- こちらは初回実行時からアカウント内でストアドプロシージャを作成していなかったのでどうして検出されたのか、と思っていましたが再度実行すると表示されなくなりました。
4.10 Ensure that data masking is enabled for sensitive data
- こちらは意図した通り、アカウント内でマスキングポリシーを作成したので、検出されなくなっていました

セキュリティリスクの修復で「1.5 Ensure minimum password length is set to 14 characters or more」について、指示通りアカウントレベルのパスワードポリシーを設定し、以下でもアクティブであることを確認できたのですが、ここでは表示は消えませんでした。（既存ユーザーのパスワードも14文字以上）

select *
from table(snowflake.information_schema.POLICY_REFERENCES(
REF_ENTITY_NAME => 'アカウント識別子',
REF_ENTITY_DOMAIN => 'ACCOUNT'
));

また、違反するユーザーとして SNOWFLAKE も表示されていました。

Why a user 'SNOWFLAKE' exists in an account | Snowflake Community

コスト

Trust Center によるスキャナーの実行には、サーバーレスコンピューティングコストが発生します。SERVERLESS_TASK_HISTORY ビューから、Trust Center のコストを監視できます。
こちらも公式ドキュメントにサンプルクエリの記載があります。例えば以下のクエリを実行してみます。

SELECT * FROM snowflake.account_usage.serverless_task_history;

出力は下図のようになり、ベンチマークの項目ごとにクレジット消費量がわかるようになっていました。

初回実行後に以下のコマンドで合計のクレジットを算出してみました。

SELECT SUM(CREDITS_USED)
  FROM snowflake.account_usage.serverless_task_history
  WHERE
    DATABASE_NAME = 'SNOWFLAKE' AND
    SCHEMA_NAME = 'TRUST_CENTER_STATE' ;

出力は下図の通り、ここではおよそ 1クレジットの消費でした。

再実行後、それぞれの実行についてクレジットを確認してみると、この環境での2回目実行時は大幅にコストが減少していました。サーバレスタスクのように Snowflake 側で最適なサイズに設定してくれているのでしょうか。

 SELECT START_TIME,SUM(CREDITS_USED)
  FROM snowflake.account_usage.serverless_task_history
  WHERE
    DATABASE_NAME = 'SNOWFLAKE' AND
    SCHEMA_NAME = 'TRUST_CENTER_STATE'
  GROUP BY START_TIME
;